[00:00.000 --> 00:05.580]  This talk is about my search for a good UPnP hacking tool.
[00:06.340 --> 00:11.340]  So what we're going to go over today is just some introductions to tell you who I am.
[00:12.020 --> 00:16.320]  First I'll start talking about what is UPnP and why should you care about UPnP?
[00:16.560 --> 00:20.120]  Why was I looking for a tool to hack UPnP in the first place?
[00:20.620 --> 00:25.740]  I'll talk about some of the tools that are out there right now and what I found to be
[00:25.740 --> 00:29.680]  their shortcomings and why I thought that they weren't quite sufficient.
[00:29.980 --> 00:37.900]  I will show you a new, an updated tool that I put a lot of updates into and I'll talk
[00:37.900 --> 00:39.360]  about the features of that.
[00:39.360 --> 00:44.000]  And throughout we'll do some demos of that functionality and about UPnP in general.
[00:44.580 --> 00:50.360]  Q&A was going to be in the Discord chat, but I know Discord is down at the moment or there's
[00:50.360 --> 00:51.600]  some issues with it.
[00:51.600 --> 00:58.760]  So if that still happens, we'll probably just keep the Q&A here in the Twitch channel.
[00:59.880 --> 01:01.360]  All right, so who am I?
[01:01.360 --> 01:03.620]  Real name is Trevor Stavato.
[01:03.620 --> 01:06.880]  I've been in offensive security for over 10 years.
[01:07.580 --> 01:13.160]  Different positions, mostly in web app and network pen testing.
[01:13.480 --> 01:17.880]  A couple of years ago, I founded this cool little company called LabMath Security.
[01:19.400 --> 01:24.380]  Before I was in hacking, I was a software developer and I did that for a number of years
[01:24.380 --> 01:28.340]  and then realized all the mistakes I was making once I became a hacker.
[01:29.220 --> 01:32.740]  I try to be an active member of the security community.
[01:32.780 --> 01:37.140]  As Sam said, I help do some IoT village stuff in Canada.
[01:37.140 --> 01:39.200]  I help sometimes in the U.S. as well.
[01:40.200 --> 01:42.680]  I like to dabble a little bit in RFID.
[01:42.680 --> 01:45.280]  So we do an RFID village here in Canada.
[01:45.280 --> 01:49.260]  And I do some red teaming for the pros versus Joe CTF,
[01:49.260 --> 01:53.320]  which unfortunately didn't happen this year because of all this COVID stuff.
[01:54.360 --> 02:01.400]  Maybe one of my proudest achievements so far is the DEF CON 26 black badge win at the IoT CTF.
[02:02.640 --> 02:06.220]  All right, so let's talk about what UPnP is.
[02:06.220 --> 02:09.320]  So UPnP is Universal Plug and Play.
[02:09.320 --> 02:16.800]  And it's a protocol defined, I think back in 2008 was the original publication of this protocol,
[02:18.000 --> 02:22.100]  allowing for devices on network to discover and interact with each other.
[02:22.100 --> 02:25.820]  It's based around a principle called zero configuration networking.
[02:26.260 --> 02:30.660]  Really what they wanted to be able to do was to have a device that just plugged into a network,
[02:30.660 --> 02:34.420]  found other devices and was able to talk to and communicate with the other devices
[02:34.420 --> 02:38.760]  and have them configure themselves according to their needs
[02:38.760 --> 02:44.140]  without anybody having any actual input and hands-on keyboard configuration.
[02:44.700 --> 02:47.140]  Sounds like a great idea to me.
[02:48.200 --> 02:55.740]  So UPnP is a protocol that uses pretty standard services like HTTP, XML, and SOAP.
[02:55.740 --> 03:01.760]  And it defines a way for services to describe their functionality and interact with other devices.
[03:02.220 --> 03:06.100]  A lot of the common uses for this are for network services.
[03:06.100 --> 03:12.840]  So small office, home office routers will use this for configuring port forwarding.
[03:13.480 --> 03:20.320]  There's data sharing services for network storage, media streaming, for example, Chromecast,
[03:20.320 --> 03:25.660]  or some of the original versions of Chromecast use UPnP to initiate the streams.
[03:25.680 --> 03:27.900]  And it's also used commonly in smart home control,
[03:27.900 --> 03:31.000]  which will be one of the demos that we're doing later on today.
[03:33.200 --> 03:40.720]  So in the spec, UPnP talks about kind of six capabilities or six things that are required
[03:40.720 --> 03:45.140]  for proper UPnP functioning. The first one is addressing.
[03:45.620 --> 03:50.700]  It's not as important for the tool because we can't really talk to it unless it has a device,
[03:50.700 --> 03:55.820]  but the device needs a way to get an IP address. And this is typically done through DHCP.
[03:57.160 --> 04:01.080]  The second one, more interesting to us, is a discovery protocol.
[04:01.080 --> 04:06.980]  The devices need to be able to advertise their presence on the network, or other devices need
[04:06.980 --> 04:12.860]  to be able to search for other UPnP devices on the network. So there's a protocol called
[04:12.860 --> 04:18.280]  Simple Service Discovery Protocol, SSDP, that is used to do this advertisement.
[04:18.280 --> 04:21.920]  And I'll show one of those requests later and show how that works.
[04:23.240 --> 04:28.820]  Once you know what devices are on the networks, you need to know what those devices can do.
[04:28.820 --> 04:36.240]  And then there's a device description XML file that gives this detail. And when the devices
[04:36.240 --> 04:42.000]  broadcast their presence or another device searches for them, the URL to that XML file
[04:42.000 --> 04:50.170]  is part of the response that comes back. The next part is control. So once you know
[04:50.170 --> 04:55.050]  what it can do, you need to know how to control that device. You need to know what endpoint to
[04:55.050 --> 05:02.290]  send the request to, what parameters you need to include in the request. Once you have this
[05:02.290 --> 05:06.630]  information, now that's enough information to start interacting with that device.
[05:07.270 --> 05:14.090]  There are still a couple of other parts to UPnP. The fifth one is event notification. So
[05:14.710 --> 05:20.490]  you can subscribe to specific state variables on a device. And if that state variable changes,
[05:20.490 --> 05:27.110]  it'll send a notification to you. And then the last part of UPnP protocol is a presentation.
[05:27.810 --> 05:33.250]  For the topic of this talk, that's not as important, because that just gets into sort
[05:33.250 --> 05:39.990]  of regular web app hacking, less UPnP hacking. So we're going to focus on two to five with this
[05:40.450 --> 05:52.970]  talk. So I'm going to show you just a brief view of a device description and what that kind of
[05:52.970 --> 06:00.210]  looks like. So over here, I'm going to run a search. And you'll see the discovery message.
[06:00.210 --> 06:03.370]  And I'll make this bigger, because this might not be easy for people to see.
[06:07.200 --> 06:16.180]  So there's a discovery message that uses a custom HTTP verb called msearch. It posts to a
[06:16.180 --> 06:23.560]  broadcast address. And this is just a fixed... this is the same on every network. It's got a
[06:23.560 --> 06:30.820]  message saying, try SSDP discover, and the service type in this case is SSDP all, which basically
[06:30.820 --> 06:36.680]  says, all devices respond to me. And you can see the responses come back here from all the
[06:36.680 --> 06:45.960]  different devices, showing you here is the location of my device description. And it'll
[06:45.960 --> 06:52.780]  also give you some information about what kind of device it is. So you can see on my network,
[06:52.780 --> 06:57.620]  there are a couple devices that have a lot of different services. Because we said SSDP all,
[06:57.620 --> 07:05.540]  all the services are responding separately. So now I'm going to... we're going to take a look at
[07:05.540 --> 07:17.130]  one of these. And we'll show you what a device description looks like. And make this bigger.
[07:19.070 --> 07:25.030]  So this here, you can see my setup here on the other screen. I have an Asus router,
[07:25.030 --> 07:30.050]  I have a WeMo switch, and that is, there's a little lamp plugged into that WeMo switch.
[07:30.450 --> 07:36.550]  So the device description we're seeing here is for the Asus router. It shows you the model number,
[07:36.550 --> 07:42.350]  the version numbers, serial number, a lot of information about it. When we get down into
[07:42.350 --> 07:47.910]  this section, the service list, this is where we see the different services, the UPnP services
[07:47.910 --> 07:53.950]  that it supports. So it'll show you the URL that you need to send control requests to,
[07:53.950 --> 08:03.170]  the URL to send event requests to. And it'll also have, not in this one, but in some of them,
[08:03.170 --> 08:09.690]  it'll have the, oh yeah, no, here it is, the SCDP, so the service controlled
[08:11.410 --> 08:17.330]  description, so the service description. So if we copy this, and we put this on here,
[08:17.330 --> 08:27.350]  we'll now put a double X bar, there we go. Now we'll see all the actions that this service
[08:27.350 --> 08:34.010]  supports, action name, and all the arguments. So we can collapse all this, and you can see there's
[08:34.010 --> 08:39.310]  gonna be a bunch of actions for this service. And then we get into this server state table that
[08:39.310 --> 08:45.210]  talks about all the state variables. And some of these won't send events, so the send events is no,
[08:45.210 --> 08:50.250]  but some of these do. And those are the ones that we can subscribe to. So physical link status
[08:50.250 --> 08:57.030]  is a variable that we can subscribe to and get notifications when that status changes.
[08:57.190 --> 09:04.630]  So you can see how this can be used by devices to monitor what's happening in the network and be
[09:04.630 --> 09:12.150]  able to control it. So that's the overview of how the service descriptions and device
[09:12.150 --> 09:20.340]  descriptions work and what they look like. So one thing that's missing from this spec
[09:21.080 --> 09:25.440]  is that there's no authentication. Even on the control endpoints, when you're sending a control
[09:25.440 --> 09:31.800]  message, they are unauthenticated. It's a very old protocol, as I said, 2008, so they probably
[09:31.800 --> 09:38.460]  didn't think about that part of it. There have been some updates, some other optional pieces
[09:38.460 --> 09:44.680]  that you can tack on to add some authentication and some security to it. But those really,
[09:44.680 --> 09:49.800]  from my experience, I haven't seen any devices that use those. So most of this is just fully
[09:49.800 --> 09:59.120]  done unauthenticated. So why does this relate to IoT? Why is it in IoT Village? A lot of IoT devices
[09:59.120 --> 10:06.980]  are using UPnP. It makes them very simple for setup and control. A lot of consumer devices,
[10:06.980 --> 10:11.200]  they just want to make it simple. You take it home, you plug it in, and it works. So that's
[10:11.200 --> 10:18.780]  why UPnP is helpful for that. But as a hacker, we can look at what can we do with that. So we can
[10:18.780 --> 10:24.520]  do things like turning smart home devices on and off. And I'll do a demo later of the Wemo switch
[10:24.520 --> 10:31.680]  turning that on and off. One of the other things that UPnP has gotten the news a lot for is the
[10:31.680 --> 10:40.220]  ability to update the router's configuration and open ports on the router so that you can forward
[10:40.220 --> 10:46.400]  from the WAN side, the internet side, into the internal network. And then, as I said, you can
[10:46.400 --> 10:53.340]  also control media devices. So I thought IoT has already so many vulnerabilities. There's got to be
[10:53.340 --> 11:01.020]  some UPnP vulnerabilities, right? So that's why I wanted to look at UPnP as sort of an attack path.
[11:02.220 --> 11:08.940]  As I said, there's been a couple of notable exploits in the news. Back in 2017, Akamai
[11:08.940 --> 11:19.000]  released a paper talking about UPnProxy, UPnProxy. Basically, a lot of devices were configured to
[11:19.000 --> 11:28.100]  expose the UPnP interface on their WAN, on the WAN side. So you could send control events,
[11:28.100 --> 11:35.020]  things like port forwarding from the WAN side. So somebody on the internet could control your
[11:35.020 --> 11:40.760]  router and could set port forwarding to get internal access to your network. And even some
[11:40.760 --> 11:46.060]  of the rules, the way that they were doing the port forwarding, they're not validating the field.
[11:46.060 --> 11:53.120]  So you could port forward a port on the WAN side and forward it to a completely different URL
[11:53.120 --> 11:58.900]  somewhere else on the internet. So people were using this as a proxy, as their UPnProxy,
[11:58.900 --> 12:03.600]  to hide where they're coming from and sort of disguise their attacks.
[12:04.260 --> 12:12.720]  Back in 2019, there was a pretty famous attack from HackerGiraffe, where they used basically
[12:12.720 --> 12:18.980]  that same functionality, routers that were allowing configuration on their WAN side,
[12:18.980 --> 12:24.940]  to port forward to the Chromecast device. And then from there, they could control the
[12:24.940 --> 12:31.040]  Chromecast device, because it used UPnP as a way to stream a video to it. So they could control
[12:31.040 --> 12:37.420]  the Chromecast device and put a video of their choosing on. And they decided to put up an
[12:37.420 --> 12:42.060]  advertisement to subscribe to PewDiePie. So that got a lot of news headlines.
[12:42.760 --> 12:48.480]  One of the more recent ones that I've come across is this vulnerability called Call Stranger.
[12:49.020 --> 12:53.360]  And it's a 2020 vulnerability. It's really interesting when you look at this, because
[12:53.360 --> 12:58.620]  basically what he did is he looked at the UPnP spec and just noticed that there's some
[12:59.240 --> 13:08.560]  bad design in the spec. So I talked about the event subscription part of this. There's a callback
[13:08.560 --> 13:12.800]  of the event subscription. So you tell it where to call back when something changes.
[13:12.800 --> 13:20.160]  But there's no validation at this point done on that callback. So you can have that be some other
[13:20.160 --> 13:26.060]  address on the internet. You can use it to... you can add query strings on it. So you could use it
[13:26.060 --> 13:31.240]  for data exfiltration, if you wanted to get stuff out of a network kind of sneakily. There's also
[13:31.240 --> 13:37.320]  some amplifications type ramifications to this, because you send a very small request,
[13:37.320 --> 13:42.740]  and the request that comes back or gets forwarded to that notification server is much larger in
[13:42.740 --> 13:48.120]  size. So you can potentially do some sort of denial of service using that amplification.
[13:48.740 --> 13:58.530]  So we'll look at that and show you how that's done. So when I went looking for the UPnP tool,
[13:58.530 --> 14:02.870]  there's basic things that I would want a UPnP tool to do. First, I want it to discover all
[14:02.870 --> 14:07.490]  the devices on my network. I don't want to have to go out there and look for it. I want this tool
[14:07.490 --> 14:12.070]  to be able to find them. Once it finds them, it should be able to parse the description, find the
[14:12.070 --> 14:17.130]  services and actions and events. You know, XML is pretty straightforward and easy to parse. So that
[14:17.130 --> 14:23.930]  should be straightforward. And then to be able to build and manipulate the UPnP requests, that needs
[14:23.930 --> 14:31.990]  to be something simple that I can easily do, and potentially, ideally, fuzz that interface.
[14:34.270 --> 14:39.370]  So let's look at some of the tools that are out there and how I found that they worked. Now,
[14:39.370 --> 14:44.310]  this isn't an exhaustive presentation of what's out there. These are just the more common ones
[14:44.310 --> 14:50.730]  that I've come across. The first one is Miranda. And it's available in Kali out of the box.
[14:50.950 --> 14:56.970]  Has a nice command line syntax, if you like that kind of thing. But on the con side of things,
[14:56.970 --> 15:03.610]  I found it doesn't always work. In the case, I just ran it yesterday on my home network.
[15:03.830 --> 15:08.810]  It can find the devices by doing an msearch, but it seems to have trouble parsing some of the
[15:08.810 --> 15:14.730]  service description files. So it comes back with an empty list of services, and it can't do any
[15:14.730 --> 15:21.230]  sort of control of the actions. Also, command line syntax, in my opinion, isn't as nice for
[15:21.230 --> 15:27.130]  interacting with these requests. And I just don't find it as nice to use.
[15:28.850 --> 15:32.530]  The next tool that I looked at, and I was actually really excited about this tool,
[15:32.530 --> 15:41.090]  was the Burp UPnP B-Hunter. It's available in the Burp app store. Because UPnP is HTTP based,
[15:41.090 --> 15:46.010]  XML soap, all that kind of stuff works really well in Burp. And it works really well in Burp's
[15:46.010 --> 15:50.410]  other tools, like Intruder and Repeater. So I thought this was a great place to have that
[15:50.410 --> 15:55.630]  kind of functionality. But when I started using it, there were some major problems that I had
[15:55.630 --> 15:59.170]  where it wouldn't detect all the devices on the network. Some of the devices that I knew
[15:59.170 --> 16:05.990]  were there, it wasn't picking them up. And sometimes the parsing wasn't working. It wasn't
[16:05.990 --> 16:14.030]  able to parse the service descriptions and get access to all the different control points.
[16:14.550 --> 16:20.010]  Lastly, I found the interface just wasn't so easy. My home network, I do have a lot of IoT
[16:20.010 --> 16:26.850]  devices plugged in. And when I do a UPnP scan, I get back five or six devices. Each of them have
[16:26.850 --> 16:35.430]  many service descriptions and lots of control endpoints. And the version that's in the app store
[16:35.430 --> 16:40.850]  right now basically has very little fine-grained control over what requests you send to Intruder
[16:40.850 --> 16:45.670]  or Repeater. And sometimes even you don't have control over where you send it to. It's either
[16:45.670 --> 16:51.490]  one or the other. But I was ending up with, you know, a hundred Repeater tabs of requests and
[16:51.490 --> 16:56.250]  trying to dig through a hundred tabs to find the one request that I wanted to fuzz or test.
[16:56.390 --> 17:03.890]  It's just not very user-friendly, in my opinion. So, you know, what's a wannabe UPnP hacker guy
[17:03.890 --> 17:09.910]  like me going to do? As I said, there's other tools. There are things like uFuzz that's based
[17:09.910 --> 17:14.130]  on Miranda. So it's going to have the same sort of shortcomings that Miranda has. There's some
[17:14.130 --> 17:20.430]  .NET tools, but I don't really work on a Windows laptop very much. So .NET is not that conducive
[17:20.430 --> 17:27.050]  for me. So, you know, I was kind of looking at a few different options. I keep looking,
[17:27.050 --> 17:32.650]  see if there's other tools out there. I build a new tool from scratch or I modify an existing
[17:32.650 --> 17:38.150]  tool that's already out there. So being Canadian, I turned to my good friend and my neighbor,
[17:38.150 --> 17:42.210]  Drake, and I said, what should I do? He told me, don't build a new tool from scratch.
[17:42.210 --> 17:45.190]  You got to modify something that's already existing out there.
[17:46.630 --> 17:53.550]  So that brings me to my version of Burp's UPnP Hunter. I thought that it had the best sort of,
[17:54.970 --> 18:01.230]  you know, potential for a tool because of its integration into Burp and some of the other
[18:01.230 --> 18:05.150]  tools that you can use with Burp. But first we had to get through some of the bugs that
[18:05.150 --> 18:11.110]  it was facing right now. So the first one, the fact that it didn't detect all the UPnP devices
[18:11.110 --> 18:17.190]  on the network, I found that this comes down to some devices just don't follow the spec very well.
[18:18.230 --> 18:24.310]  It was sending the msearch using an ssdp-all, which I showed earlier, and all devices are
[18:24.310 --> 18:30.450]  supposed to respond to that. But some devices, they just don't. So I added a different msearch.
[18:30.450 --> 18:36.550]  So it does two msearches, one using ssdp-all and one using another tag called root device.
[18:36.670 --> 18:40.530]  And only the root device is supposed to respond to that, not all the different services.
[18:41.170 --> 18:46.770]  That seemed, pardon me, that seemed to work a little bit better for some of the devices that
[18:46.770 --> 18:51.510]  were on my network. So I was able to find all the devices on my network at that point.
[18:52.210 --> 18:58.690]  I still had some issues though with parsing in this tool. There was an interesting unsigned
[18:58.690 --> 19:05.490]  integer conversion error. So Burp is written in Java and Java byte arrays go from negative 127
[19:05.490 --> 19:14.430]  to positive 127. But Python, which this tool is written in, has byte arrays go from 0 to 256.
[19:14.770 --> 19:21.110]  So in most characters, that doesn't really matter because you're still in the 0 to 127 range.
[19:21.190 --> 19:26.890]  But when you get into special characters and you get an assigned byte array from Java going
[19:26.890 --> 19:33.850]  into Python, things don't work so well. So I had to do some tricks to convert that back to
[19:33.850 --> 19:42.790]  an unsigned byte array. So that, you know, no matter what we got in the service description,
[19:42.790 --> 19:49.770]  special characters or not, it wasn't going to work on me. I also found that the control URLs,
[19:49.770 --> 19:55.270]  the way that it was parsing the control URLs from the device description, it didn't account for the
[19:55.270 --> 20:02.070]  fact that some devices add query strings to the control URLs. So they have a generic control URL,
[20:02.070 --> 20:09.090]  they have a query parameter that it uses to determine what service you're trying to talk to.
[20:09.190 --> 20:14.310]  Without that, it just gave me back a bad request. So I had to modify the tool to actually use the
[20:14.790 --> 20:22.750]  query string that was part of the control URL. Lastly, there were still other issues with the
[20:23.270 --> 20:29.310]  parsing. It wasn't actually doing XML parsing in the first version. It was using a regex to try to
[20:29.970 --> 20:34.210]  search through the XML document to pull out the pieces that it needed.
[20:34.330 --> 20:38.070]  And if you had an XML document that wasn't structured the way it's expected,
[20:38.070 --> 20:45.670]  then it wouldn't work. So I switched it to use actual XML parsing because that just makes sense.
[20:47.330 --> 20:54.570]  I also changed the UI for the tool. Because I didn't want to have to dig through 100 tabs in
[20:54.570 --> 20:59.910]  repeater, I added some combo boxes where you can now select the IP, the service, and the action.
[20:59.910 --> 21:04.250]  So you can drill in on the specific request that you want to look at and play with.
[21:04.450 --> 21:10.650]  I added a full request viewer and editor. So you can look at that and maybe change things
[21:10.650 --> 21:15.310]  before you send it to intruder or repeater. And you have the option to send it to either.
[21:15.310 --> 21:18.770]  You're not sort of tied into one or the other like you were in the first version.
[21:20.270 --> 21:28.950]  And lastly, I added a couple new features to the tool. So I added the ability to subscribe to event notification.
[21:28.950 --> 21:35.630]  So it parses that service description, looks for state variables that have events turned on,
[21:35.630 --> 21:40.290]  and then it will build a request for you that you can generate a subscribe request
[21:40.850 --> 21:47.950]  to subscribe to those state variables. I also added an option to specify the single device
[21:47.950 --> 21:54.230]  description. So instead of searching your network, you can specify a remote service description.
[21:54.290 --> 21:58.750]  Searching only works on your local network because you're broadcasting to an address
[21:58.750 --> 22:03.070]  within your local network. So only devices within that local network are going to work.
[22:03.250 --> 22:08.850]  But if you go on Shodan, there's a lot of UPnP devices on Shodan that are exposed to the internet.
[22:08.850 --> 22:12.930]  If you want to play with those, now you can because you can paste that service description
[22:12.930 --> 22:19.930]  into there directly and load that and get all the actions. I also added some little buttons
[22:19.930 --> 22:25.330]  so you can view, pull up the service description and SCDP files directly from the tool.
[22:25.370 --> 22:29.690]  That was kind of more of a convenience for me as I was debugging and trying to figure out
[22:29.690 --> 22:34.170]  why things weren't working. To easily get to the device description and those files
[22:34.170 --> 22:41.950]  made it a little bit easier to see what I'm looking at. And now it's demo time. So we'll go through
[22:41.950 --> 22:51.410]  that tool and show you what it actually does. So UPnP Hunter 2.0. Right now it is not available
[22:51.410 --> 22:56.810]  in the Burp App Store. I do plan to push it to the Burp App Store at some point later.
[22:56.810 --> 23:02.270]  I first wanted to wait and give the original author a chance to pull in some of the changes
[23:02.270 --> 23:09.190]  that I pushed and maybe update the tool from there. He doesn't seem to have the interest
[23:09.190 --> 23:15.610]  to do that. So I will push this as a separate standalone version. So this is the tool. This
[23:15.610 --> 23:20.370]  is what it looks like in the Burp tab. And I'm just going to go ahead and start a discovery
[23:20.370 --> 23:25.350]  on my network. And this will take a few minutes. Because as I said, it's running the
[23:27.350 --> 23:32.170]  mSearch, reading back all the responses and then parsing out. So on this network,
[23:32.170 --> 23:38.050]  I have two devices that are running UPnP. This is the ACES router as we saw before.
[23:38.050 --> 23:45.390]  This one is the Belkin WeMo device. And this is the list of all the service endpoints that
[23:46.170 --> 23:52.150]  it understands. And if you look at the different actions, these are all the actions within that
[23:52.150 --> 23:57.490]  service endpoint. So I'll just pull up the SCDP here for a second. And so you can see,
[23:57.490 --> 24:01.630]  you know, action, get device information. That should be in here somewhere. Yeah,
[24:01.630 --> 24:06.690]  get device information. And then once you select it, it pulls up the request,
[24:06.690 --> 24:13.730]  builds out the request in this field here. So you can view it, see what different parameters
[24:13.730 --> 24:19.670]  it takes. And then you can send that straight to Repeater or to Intruder. And you'll see that
[24:19.670 --> 24:24.470]  Repeater picked it up. And now it's here. And I can send this request and get device information
[24:24.470 --> 24:33.450]  from that device. So that's, you know, very basically, that's how it works. So let's show
[24:33.450 --> 24:39.570]  you why this is cool and, you know, what we can do with this. So one of the things that's very
[24:39.570 --> 24:47.330]  easy to do with the Belkin WeMo device is controlling its on and off state. So it's
[24:47.330 --> 24:55.610]  called binary state. So we are going to find the request set binary state. And we can see there's
[24:55.870 --> 25:01.530]  a few different parameters here. And the parameter values are just filled with fuzz here to tell you
[25:01.530 --> 25:08.070]  where you can actually put input. And we'll send that to Repeater. We'll take all this fuzz here
[25:08.070 --> 25:19.000]  stuff out. And the only one that really is needed for most basic operation is the binary state. So
[25:19.000 --> 25:25.320]  I'm going to set the binary state to one, which should be on. And as you see over here, the light
[25:25.320 --> 25:32.600]  flips on and I get a response that now the binary state is on and some other information. And now I
[25:32.600 --> 25:38.600]  can set the binary state back to zero and the light goes off. So very simple, easy control of
[25:38.600 --> 25:52.860]  the device state through UPnP. Let's talk a little bit about event subscription. So in here, you will
[25:52.860 --> 26:02.100]  see a subscribe request. And it again uses a custom HTTP verb, subscribe. This is the path
[26:02.100 --> 26:06.980]  pulled out of the device subscription. And then again, there's a bunch of places where you can
[26:06.980 --> 26:14.500]  fuzz. Here in this section is where you put the parameters that where you want the callback to
[26:14.500 --> 26:21.180]  come to. You can set a timeout for how long you want to get notified of those event changes. And
[26:21.180 --> 26:27.960]  then this is a comma separated list of all the different parameters that this device will give
[26:27.960 --> 26:34.980]  event notifications for. So I already have one of these queued up over here. Let's see.
[26:35.460 --> 26:42.460]  So if everything is still working the way it should, I will get a device subscription,
[26:42.460 --> 26:55.340]  or sorry, event notification here saying the... that is not what I expected. Hang on a sec.
[26:56.420 --> 27:03.340]  Property change. Property state is zero. Okay. Sorry. That is what I expected.
[27:03.860 --> 27:11.300]  Now if I go back to the basic event request and I change the state back to one,
[27:12.060 --> 27:18.700]  now I get another notification coming in on that callback with the binary state is one. So we see
[27:18.700 --> 27:25.220]  the notifications and how they come back. What's interesting about the notifications and what this
[27:25.220 --> 27:31.320]  call stranger vulnerability sort of talks about is you can specify multiple endpoints that this
[27:31.320 --> 27:40.040]  calls back to. One of the neat sort of features of this is that if the first request doesn't... if
[27:40.040 --> 27:45.900]  the first URL doesn't... it can't reach it, it doesn't get a response from it, then it will try
[27:45.900 --> 27:52.780]  the next request, the next IP. So you can actually make use of this to do some internal port scanning
[27:52.780 --> 28:00.080]  of things on the network. If you can access this on the WAN side, for example, you can use this
[28:00.080 --> 28:05.380]  feature, specify a host and a port, and then specify a host and a port that you know it can
[28:05.380 --> 28:14.900]  reach. And if you get the callback coming to your IP address, you know that it wasn't able to connect
[28:14.900 --> 28:22.460]  to the previous one. So that's kind of a fun little thing you can do with the subscribe feature.
[28:22.780 --> 28:28.960]  But really, that's, I guess, sort of the end of my demonstration of this tool. I think it
[28:28.960 --> 28:34.140]  can be really powerful, especially being able to send stuff to intruder and do some fuzzing
[28:34.140 --> 28:41.620]  with this. And I can also show you here that if we just take this device description,
[28:42.160 --> 28:47.960]  paste it in here, then we get just that device descriptions services. We don't get all the
[28:47.960 --> 28:52.760]  other. So you can use that as well to sort of narrow down or look at remote ones, like I said.
[28:54.540 --> 29:00.780]  And I think that is it. So the repository for this is in our GitLab. The link is here.
[29:01.580 --> 29:04.800]  As I said, I do plan on pushing this to the Verp app store
[29:04.800 --> 29:09.000]  at some point in the future, but it's just not there right now.
